Over the past several decades remote monitoring of complex hardware, software and physical systems has become more commonplace. The proliferation of remote monitoring has been facilitated by the increased sophistication and speed of digital communications media. In typical remote monitoring systems, a centralized management server receives notifications regarding the status of various monitored components from software agents installed on those components. Typically, the software agents will send out status notifications at the same frequency and in the same manner regardless of the state of the monitored component. Thus, whether a component is functioning properly or exhibiting an error, the software agent associated with that component will send out notifications at the same frequency. In a large system, this can lead to an overabundance of notifications.
In order to provide a more manageable set of notifications to an operator, many prior art systems employ a network management station (“NMS”) at the centralized management server that provides a common human interface for receiving the notifications and allowing the operator to select which notifications to view. The operator can configure the NMS to display only a subset of the notifications received so that the operator does not have to view every notification received by the centralized management server.
While the NMS can reduce the number notifications viewed, the notifications are still sent from the software agents. If the software agents send a large number of notifications, the notifications may require a large amount of bandwidth, saturating and slowing the network conducting the notifications. Moreover, if the operator configures the NMS to display too many notifications, he or she might be conditioned to ignore the alarms. If, on the other hand, the operator configures the NMS to filter out too many of the received notifications, he or she may never see important notifications, again missing alarm conditions.
One example of a common system displaying the inadequacies of prior art notification systems is a computer network employing simple network management protocol (“SNMP”) to monitor network components. SNMP was developed in the 1980's as a simple protocol that could be implemented to manage a variety of heterogeneous systems. Originally, SNMP was intended as a stopgap measure until a more robust protocol could be developed. However, the wide adoption of SNMP made it the de facto standard for internetwork management.
SNMP generally works on a server agent architecture with agents capable of using the SNMP protocol installed on each monitored component, in some cases as a portion of the firmware. The agent can send notifications, known as SNMP traps, to advise the centralized management server when one or more conditions at the monitored component has been met. In typical SNMP systems, an SNMP trap is sent every time this set of conditions is met.
In many prior art systems, the software agent will be configured to send out an SNMP trap with the monitored component's status information regardless of whether the component is functioning properly or whether the component is malfunctioning. This can lead to the software agent communicating a large volume of SNMP traps to the centralized management server. The operator, through an NMS, will then determine which SNMP traps to view. If the operator chooses to view a large number of the SNMP traps, he or she may miss alarm conditions due to information overload. Conversely, if the operator sets the NMS to filer too many SNMP traps, the operator may never see an SNMP trap indicating an alarm at a monitored component.
To reduce the number of SNMP traps sent, some prior art systems define several levels for notification behavior. Examples of such levels include a level in which all alarm messages, but no other notifications, are sent by the software agents, a level in which all SNMP traps are sent by the software agents, or a midlevel in which both SNMP traps indicating normal operation and alarm conditions are sent by the software agent according to some predefined rule. However, these systems only provide a course control that is typically applied to all the software agents (or SNMP traps of those agents). They do not allow fine control for tuning a particular SNMP trap to send out notifications at, for example, different frequencies or for adjusting the behavior of the particular SNMP trap depending on the status of the component being monitored by the SNMP trap.